home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-isis-atipx-00.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
61KB
|
1,416 lines
ISIS Working Group Radia Perlman
Internet-draft Chris Gunner
Digital Equipment Corp.
June 1993
Further Integration of IS-IS;
Appletalk, IPX, and Other Protocols
Table of Contents
1. Status of this Memo 2
2. Abstract 2
3. Introduction 2
4. Issues To Consider 3
4.1. Disambiguating Native Mode Packets 3
4.2. Disambiguating Encapsulated Packets 3
4.3. When Is Encapsulation Desirable? 4
4.4. Metrics 5
4.4.1. IPX Ticks Metric 6
4.5. Propagation Of Protocol Y Routing Information 7
4.6. Limited Interconnectivity Over The Backbone 9
4.7. Making Configuration Easier 10
4.8. Accomodating Overlapping Addresses 11
4.9. When To Encapsulate 12
4.10. Tunnel Protocol 13
4.11. Routing Algorithm 14
5. Specific Proposal 15
5.1. Data Packet Encapsulation 15
5.2. "Protocols Supported" Field 16
5.3. Network Management Information 16
5.3.1. Parameters Node-wide (not Per Circuit Or Tunnel) 16
5.3.2. Parameters Per Circuit 17
5.3.3. Parameters Per Tunnel 17
6. Appletalk Specific Proposal 18
6.1. Appletalk Only Environments 18
6.2. Zone Information 18
6.3. LSPs 19
7. Specific Proposal for IPX 20
7.1. Ticks Metric 20
7.2. LSPs 21
7.3. IPX-specific Network Management Information 22
8. Security Considerations 22
9. References 22
10. Working Group information 23
11. Author's Address 24
Perlman (Internet-Draft expires end December 1993) [Page 1]
Internet-Draft Further Integration of ISIS June 1993
1. Status of this Memo
This document is an Internet Draft describing a method of
extending the Integrated ISIS protocol (defined in RFC 1195)
with routing information from additional protocols --
specifically NetWare IPX and Appletalk.
Internet Drafts are working documents of the Internet
Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. This Internet draft expires at the end of December 1993.
Internet drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
This is a draft document of the ISIS working group.
Distribution of this memo is unlimited. Please send comments to
the ISIS working group:
isis@merit.edu
2. Abstract
This document defines a method of extending the Integrated ISIS
protocol (defined in RFC 1195) with routing information from
additional protocols -- specifically NetWare IPX and Appletalk.
3. Introduction
This document describes how to add support for new protocols
into IS-IS. Once routes are calculated, a packet can either be
carried in "native mode" or "encapsulated" in a Network Layer
header supported by all the backbone IS-IS routers. This design
allows network managers to configure which types of packets are
encapsulated and which are carried in native mode.
The document describes generic support for protocols other than
IP and CLNP, and then describes specific packet formats for
support of Appletalk and IPX.
Perlman (Internet-Draft expires end December 1993) [Page 2]
Internet-Draft Further Integration of ISIS June 1993
4. Issues To Consider
4.1. Disambiguating Native Mode Packets
If multiple Network Layer protocols are being carried over a
link, there must be a way to distinguish them. There is no way
in general, by looking at the packet itself, that a protocol X
packet can be distinguished from a protocol Y packet, unless we
are extraordinarily lucky that either the independently designed
protocols happen to be defined so that no packet from one could
possibly be interpreted as a legal packet in the other, or that
the people designing protocol Y took great care to design their
packets to distinguish them from protocol X packets.
Given that we can't count on being extraordinarily lucky, we
must ensure that each data link provides a method of specifying
the protocol type of the packet. Where protocols do (Ethernet,
PPP), all that is needed is to get a value assigned for each
protocol we wish to support. Where protocols don't (HDLC), we
must provide some mechanism, for instance by adding a protocol
type field in the beginning of what HDLC considers the initial
portion of the data packet. Where a protocol defines multiple
ways of doing it (802 LANs, which provide for SAPs for a few
protocols, and SNAP SAP encoding for the others, where either 5
byte protocol types are used, or 2 byte Ethernet protocol types
are used with a prespecified OUI), we need to specify which
method should be used for each protocol supported, and define
the values.
4.2. Disambiguating Encapsulated Packets
The same problem occurs if we encapsulate various Network Layer
protocols in a Network Layer header. Some Network Layer
protocols (IP) have a "protocol type" field. Others (CLNP) do
not. Probably the simplest method of providing protocol
demultiplexing in CLNP is by adding a protocol type field to
what would be considered the beginning of the data packet, in an
encapsulated packet. In order to avoid having to administer yet
another protocol type field, we should standardize on Ethernet
protocol types (in which case the field would be 2 bytes), PPP
protocol types (in which case the field would be 2 bytes), IP
protocol types (in which case the field would be 1 byte), or 802
protocol types (in which case the field would be 5 bytes). The
other possibility is to use the bottom byte of the destination
address in CLNP (the "SEL" byte) as a protocol type field, and
define the values to be the same as IP protocol types.
In either case (if we use the SEL byte or we use the first part
Perlman (Internet-Draft expires end December 1993) [Page 3]
Internet-Draft Further Integration of ISIS June 1993
of the data as a protocol type), either we give a pointer to
some other standards body that defines protocol types, or we
have to give them out ourselves.
4.3. When Is Encapsulation Desirable?
Let's assume that all the backbone routers support at least one
common Network Layer protocol, probably IP or CLNP. Let's call
the common Network Layer protocol "protocol X". A new protocol,
say protocol Y, can be supported either in native mode or
encapsulated with a protocol X header.
Encapsulation of protocol Y packets is desirable if:
1. Not all backbone routers support protocol Y
2. There are multiple independent protocol Y networks with
overlapping addresses, and the encapsulation allows
extension of the addressing (see section on "domains").
3. Protocol Y data packet format has limited capabilities, for
instance a small maximum hop count as in the case of
Appletalk. Encapsulating Appletalk allows the entire IS-IS
backbone to be treated as a single Appletalk hop.
4. It might be easier to build high performance routers if
they only have to forward a small number of network layer
headers. So performance might actually be enhanced if there
were only one packet format in the backbone.
The disadvantages of encapsulation are:
1. It may be a performance problem for the encapsulating and
decapsulating routers. Theoretically, encapsulating in a
Protocol X header should be no different from encapsulating
in any data link header, which any router must do when it
is forwarding a packet. However, there are some router
implementations that will forward much more slowly if they
have to encapsulate or decapsulate.
2. It makes the data packets bigger.
3. If protocol Y packets can be large, it leads to the
possibility of the decapsulating router having to do
reassembly. Luckily with IPX and Appletalk, packets larger
than 576 bytes are not allowed, so we can avoid
fragmentation.
Perlman (Internet-Draft expires end December 1993) [Page 4]
Internet-Draft Further Integration of ISIS June 1993
4.4. Metrics
Network Layer protocols evolve with their own routing protocols
and metrics. If we were to support only protocol Y end systems,
things would be much simpler, but we have to assume there are
islands of protocol Y routers, and we have to interact with them
without expecting anyone to modify the code in the protocol Y
routers.
Appletalk and IPX both compute a metric of hops (though IPX
additionally computes a metric known as "ticks"). Both Appletalk
and IPX use a protocol similar to IP RIP, and the maximum hops
that can be reported is 15. The ticks metric for IPX is rather
critical, since it is intended to give the Transport Layer a
good estimate of the round trip delay. The IPX Transport layer
does not measure round trip delay and adapt to it -- it takes
the ticks value and sticks with it for the duration of a
conversation (based on my knowledge of IPX).
In this part of the paper, when we are discussing protocols
generically, we will refer to "the RIP-like routing protocol
that routes Protocol Y" as "GRP", for "Generic Routing
Protocol".
IS-IS has a link cost of between 1 and 64 (at least for CLNP and
IP -it can be larger when reporting other protocols since the
option for reporting a protocol Y destination in an LSP is not
yet defined). If there is an IS-IS router R2 with a GRP neighbor
R1, and R2 has computed a path cost to protocol Y destination D
as 227, what is R2 supposed to report in its GRP message to R1?
It is dangerous to ever decrease a metric, since the
reachability of D can leak out some other part of the GRP
island, and routing loops can be created, since D can look
closer from the other end of the GRP island, even though D is
not reachable within the GRP island.
Various possibilities are:
1. Scale GRP metrics to IS-IS metrics. For instance, if the
maximum path cost in IS-IS is 1023, then each GRP hop might
be declared to equal a cost of 64. This requires the
ability of reporting a link cost equal to 1023 (more than a
byte).
2. Use hops (or whatever the protocol Y metric is) whenever
reporting cost to a protocol Y destination. The way this
would work is, suppose level 1 IS-IS router R2 is attached
to GRP router R1. R2 hears, through GRP, that R1 can reach
D at a cost of 5. R2 reports "6" in its LSP as the cost to
D. Level 2 router R3, in the same area as R2, needs to
Perlman (Internet-Draft expires end December 1993) [Page 5]
Internet-Draft Further Integration of ISIS June 1993
report D in its level 2 LSP. It can figure out the number
of hops on its IS-IS path to R1, add that to 6, to get the
number of hops R3 should report as its distance to D. This
has problems in that unless all level 2 routers in the area
report D, and unless all level 2 routers in a foreign area
leak information about D into their LSP, the apparent cost
to D can rise quickly, and become greater than 15
----------+ +---------+===========+----------+
D GRP | | | level | |
cloud R1--+-R2 area R3 2 net R4 area R5--R6
----------+ | | | |
+---------+===========+-----------+
3. A variant on the previous strategy is to only increment
hops by 1, each time the cost to D is leaked from level to
level. So in the previous case, R2 would report 6 in its
LSP, as the cost to D. R3 would report 7. Level 2 router R4
in a foreign area would report 8. Level 1 router R5 in R4's
area would report 9, to a GRP neighbor R6.
I'll call this method "pseudo-hops".
Pseudo-hops has two slight disadvantages. First of all, it
does not allow computation of optimal interarea paths,
since there's no way to really compare the cost of the path
to D through two different level 2 routers. (But there is
no real reason to optimize Protocol Y routes when we feel
it is OK to send interarea CLNP traffic to the nearest
level 2 router). Second of all, it means (as in the case of
Appletalk), that a destination might appear reachable to
routing, but actually be unreachable because the path is
more than 15 hops, and therefore the data packet will not
survive the journey. Again, this is not too serious. If
this is a problem then the network can be configured to use
encapsulation when actual paths exceed 16 hops, if there is
a protocol with that limitation.
I advocate advertising reachability of protocol Y destination D
with either a real IS-IS cost or with pseudo-hops. A real IS-IS
cost is preferable and is used when D is directly reachable from
the IS-IS router reporting D in its level 1 LSP. Pseudohops is
used when the reachability of D is discovered through GRP, when
summarizing information into or out of an area.
4.4.1. IPX Ticks Metric
With IPX, we need to be able to give a reasonable approximation
to what IPX RIP would calculate as ticks. I suggest we report
Perlman (Internet-Draft expires end December 1993) [Page 6]
Internet-Draft Further Integration of ISIS June 1993
two metrics when reporting IPX destinations. The first metric
will either be an IS-IS cost or pseudohops. It is used for
actually calculating the path to the IPX destination. The second
metric is ticks. We could require every link in the network to
be configured with a ticks cost in addition to other metrics.
Instead, I'd recommend that we configure a "ticks scaling"
parameter. IS-IS metrics ought to be roughly proportional to
delay, just like ticks are. However, they might be scaled
differently than IPX nodes are expecting. If IPX is integrated
into an already operating network, it is not reasonable to
reconfigure all the link costs so that the ticks metric will be
right. Instead, giving a scaling factor, like saying that the
IS-IS configured default metric is 5 times the IPX ticks, (and
you'd round up after division) will probably suffice.
4.5. Propagation Of Protocol Y Routing Information
With CLNP and IP, level 1 routers only need to know which
destinations are reachable in the area. If a destination is not
reachable within the area the packet is sent to the nearest
level 2 router. With CLNP the area is explicitly in the address.
With IP, any address not reachable in the area can be concluded
to reside outside the area. CLNP was designed for hierarchical
routing. The reason IP routing can work this way is because of
the ability to summarize a lot of destinations by advertising a
short mask. In the case of IP, it is possible to advertise
"default route", which is a mask of all 0's.
Unfortunately, IPX and Appletalk have no means of summarizing
routing information. Even if IS-IS routers were capable of
coping with the concept that anything not reachable in the area
is reachable outside the area, they would not be able to give
routing information to a neighboring GRP router. In the case of
IPX, every network number must be explicitly stated to the RIP
neighbor, or it will assume that network is not reachable.
Likewise with Appletalk, though Appletalk does have the concept
of network number ranges. Theoretically, one could use a huge
range as sort of a "default route", but Appletalk routers cannot
cope with overlapping address ranges, and there are higher layer
protocols that need to translate from "zone names" to specific
network number ranges for the LANs on which those zones reside.
Therefore, in the case of IPX and Appletalk we do not get the
benefit of hierarchy. Information about destinations reachable
within an area must get fed into the level 2 routers, which must
in turn feed the information into all the areas.
The most straightforward method of feeding information from area
A into level 2, is for the level 2 routers in area A to compute
reachability to all relevant destinations in A, and include
Perlman (Internet-Draft expires end December 1993) [Page 7]
Internet-Draft Further Integration of ISIS June 1993
those destinations as "neighbors" in their level 2 LSP.
Likewise, after computing their level 2 reachability, they will
add to their level 1 LSPs in area A any relevant destinations
they have discovered through level 2.
If we want optimal routing to protocol Y destinations, then
every level 2 router would have to report an accurate cost from
itself to each destination. Since we believe it is reasonable to
trade off optimal routing for scaling of the routing algorithm,
we propose that only a single level 2 router in each area report
reachability information into or out of the area. We'll call
that level 2 router the Designated Level 2 IS for area A. It is
chosen based on lowest ID, of the level 2 routers in area A that
support protocol Y.
If none of the level 2 routers in area A support protocol Y, it
is possible to leak protocol Y information into and out of A
through use of a "tunnel". A tunnel in this case is manually
configured between level 1 routers in two different areas. A
router connected to a tunnel summarizes all the protocol Y
destinations reachable within its area over the tunnel. It does
not report destinations reachable from other areas that have
been discovered either through tunnels or through level 2
routers. (It is possible to require a tunnel from area A even
though level 2 routers in A support protocol Y, in the case
where area B has no protocol-Y capable level 2 routers, in order
to share information between area A and area B.)
The requirement that a tunnel between area A and B only report
reachability of destinations directly reachable from A and B
(not learned through other tunnels or from level 2) makes things
simpler, but it has the potential disadvantage that if there
were n areas that needed to be connected through tunnels, there
would need to be n**2 tunnels configured, and probably more to
handle the case of tunnel routers being down. However, if there
is a large amount of protocol Y sprinkled around the network,
and therefore many areas with protocol Y information, then the
cost of upgrading the level 2 routers to handle protocol Y
information is relatively small. If level 2 routers can handle
protocol Y information, tunnels are not necessary.
We will make the restriction that Protocol Y information leaked
out of area A (either through tunnels or into level 2) only
include Protocol Y destination reachable within the area. The
way this is enforced is to mark, in level 1 LSPs, whether
Protocol Y destination D is reachable within the area or not
(the "I/E" flag, see section 4.2). (Level 2 LSP does not need
the flag since none of the information is intra-area.) R learns
of D, and therefore reports it in its level 1 LSP in one of the
following ways:
Perlman (Internet-Draft expires end December 1993) [Page 8]
Internet-Draft Further Integration of ISIS June 1993
1. R has been manually configured that D is reachable on one
of its circuits (in which case R sets the flag, indicating
D is intra-area).
2. R learned about D through a GRP neighbor (in which case R
sets the flag)
3. R is a level 2 router, and has learned about D through its
level 2 LSP database (in which case R clears the flag)
4. R is a tunnel endpoint, and has learned about D through the
tunnel (in which case R clears the flag)
4.6. Limited Interconnectivity Over The Backbone
It is possible that someone has many independently grown
Protocol Y islands, and would like to interconnect some of them.
The easiest way is to attach them all to the common backbone.
But it may not be desired to provide full logical connectivity
for various reasons:
1. Since Protocol Y (for Y=Appletalk or IPX at least) is not
hierarchical, the total amount of information in IS-IS
might be too great. It might be desired to limit the spread
of knowledge of certain islands, since it is known that
they do not need to communicate beyond a particular extent.
2. There might be security reasons why only some of the
islands should be allowed to communicate with other
islands.
3. There might be overlapping addresses. Proper use of CLNP
and IP require acquiring guaranteed unique addresses. This
is not true of IPX and Appletalk, so merging networks will
not necessarily work.
The method of accomplishing this is to allow configuration of
when protocol Y information should be propagated. The places
where such configuration is necessary are:
1. At a level 1 router -- each link should be configurable
about which types of Protocol Y information should have
routing information propagated across the link. For
instance, in the case of IPX and Appletalk, each link would
be independently configured as to which network numbers
should be included in GRP information sent on that link,
and as to which network numbers should be accepted from GRP
for inclusion in level 1 LSPs, and propagation to other GRP
neighbors on other links. So for each link, the level 1
Perlman (Internet-Draft expires end December 1993) [Page 9]
Internet-Draft Further Integration of ISIS June 1993
router will be configured with a set of network numbers it
should propagate to the link, and a set of network numbers
to propagate from the link. Also, the level 1 router should
be configured with a set of network numbers it should
propagate to level 1 routing, and a set of network numbers
it should propagate from level 1 routing to any link.
This should be wildcardable in various ways -- either by
specifying a domain (see next section), or specifying a
very wide network number range.
2. At a level 2 router -- it must be configurable with network
numbers it should pass from level 1 into level 2, and vice
versa.
3. At a tunnel endpoint -- same configuration as for a level 2
router
4.7. Making Configuration Easier
It is usually the case that for management purposes an entire
island would be treated identically, in terms of where
information about that island should propagate. At the expense
of putting a small additional field into LSPs, it is possible to
give an island a "domain" name, which could be simply a one byte
field, though we may prefer a different format in order to be
compatible with AURP. Then, instead of configuring a node with
all the explicit network numbers to be propagated, instead the
information can be summarized with a domain number.
-------------+ +---------+===========+----------+
GRP | | | level | |
cloud R2--+--R1 area R3 2 net R4 area R5--R6
-------------+ | A | | B |
+---------+===========+-----------+
|
R8--- area C
For instance, R1 might be configured to declare all network
numbers it hears from R2 as in "domain 7". It might further be
configured that it should propagate information about everything
in domain 7 into its level 1 LSP. R3 might be configured to
propagate information about domain 7 into its level 2 LSP. R4,
on the other hand, might be configured to ignore information
about domain 7. R8 might be configured to accept information
about domain 7. With very little configuration, information
Perlman (Internet-Draft expires end December 1993) [Page 10]
Internet-Draft Further Integration of ISIS June 1993
about all the network numbers in the GRP cloud is propagated to
area C, but not to area B.
So the configuration is actually two stages. First network
numbers are assigned to domain numbers. In the usual case, all
network numbers learned through GRP on a particular link will be
assigned the domain number, so this step will be very easy. In
the case of a level 2 router that is not directly connected to
any Protocol Y destinations, there will be no configuration of
network number/domain correspondence. This only occurs in
routers directly connected to Protocol Y destinations and/or
Protocol Y GRP routers. The next stage is to configure which
domain numbers should be passed to and from links or from
levels. For network numbers not assigned domains (and therefore,
by default, being in "domain 0"), or to be able to make
exceptions, it should be possible to configure network numbers
in addition to domains, in the filtering information.
4.8. Accomodating Overlapping Addresses
There is an additional way in which domains may be useful. They
may be useful as an extension to the Protocol Y address, when
encapsulation is used. At the cost of adding two extra bytes to
encapsulated data packets, we can include domain information for
the source and for the destination. This allows interconnection
of Protocol Y islands, even if they have overlapping addresses.
The way this would be accomplished is:
------------+ +-----------+ +---------------------+
A GRP | | | | B |
cloud R2--+--R1 IS-IS R3---+---R4 |
-------------+ | | | GRP cloud |
+-----------+ +---------------------+
Suppose there are overlapping protocol Y addresses in the left
and right GRP clouds. R1 could be configured to assign every
network number it hears through its link to R2 as "domain 7". R3
could be configured to assign every network number it hears
through its link to R4 as "domain 12". When reporting
information in its LSP, R1 tags it with "domain 7". Likewise R3
tags the Protocol Y destinations it hears through R4.
Now suppose A wants to send a packet to B. Let's say B is on
network 3, but there's already a network 3 assigned in the left
GRP cloud. R1 must be configured with mapping information. It
must have an unused Protocol Y network number, say 51, and use
that instead of "domain 12, network 3". A will address the
Perlman (Internet-Draft expires end December 1993) [Page 11]
Internet-Draft Further Integration of ISIS June 1993
packet to network 51. When it reaches R1, R1 will change the
destination address inside the Protocol Y packet to "3" and
include "destination domain 12" in the encapsulation header (as
well as "source domain 7").
When it reaches R3, assuming that the source network number is
used in the right GRP cloud, then R3 will similarly have to
translate the source address in the Protocol Y header before
forwarding the packet for R4.
4.9. When To Encapsulate
In general we will attempt to encapsulate only if necessary. It
will be necessary to encapsulate if:
1. We wish to overcome a limitation of Protocol Y, for
instance the hop count limit in Appletalk
2. We wish to exploit domains for address mapping
3. Not all routers on the path support Protocol Y
The LSP option announcing reachability of destination D will
carry an encapsulation destination, and an indication of whether
encapsulation is necessary. As an optimization, to save room in
the LSP, the level 1 LSP that first announces D will not carry
an encapsulation destination, since it is the source of the LSP,
say R1, that is the encapsulation destination. If a level 2
router R2 then puts D in its level 2 LSP, then R2 will include
R1's address as the encapsulation destination, together with a
flag indicating whether encapsulation is necessary to get it
from R2 to D.
Destination D gets introduced into the IS-IS level 1 LSPs in
area A by a router R in area A that discovers D through one of
the following:
1. R has been manually configured that D is reachable on one
of its ports.
2. R has a GRP (protocol Y router) neighbor that announces D
in the Protocol Y specific routing protocol.
3. R is a level 2 router, and has learned about D through
level 2 LSPs.
4. R is a router with a protocol Y tunnel, and has learned of
D through the tunnel.
Perlman (Internet-Draft expires end December 1993) [Page 12]
Internet-Draft Further Integration of ISIS June 1993
In the first two cases, R will indicate that encapsulation to D
is not necessary unless R has been configured to announce D as
needing encapsulation. The network manager might do this for
many reasons, for instance to overcome hop count limits in
Appletalk data packets. R might have been explicitly configured
to announce destination D as needing encapsulation, or it might
be configured that a particular domain number should be
announced that way, and D was configured to be in that domain
number, or it might have been configured to announce all
protocol Y destinations as needing encapsulation.
In the third case (R is a level 2 router that has learned about
D through level 2 LSPs), R will indicate that encapsulation to D
is necessary if the level 2 LSP from which R hears about D
indicates encapsulation is necessary.
Otherwise, R will report D as not requiring encapsulation. The
"don't need to encapsulate" flag is only a hint. It is possible
for encapsulation to be required, even if the flag is set,
because the traffic will exit the area at the nearest Protocol-Y
capable level 2 router, and the path from that level 2 router to
D might encounter a router that is not protocol-Y capable. In
that case, the packet will get encapsulated enroute, which is
not a problem.
In the fourth case (R learned of D through a tunnel), R will
always indicate that encapsulation is necessary.
When receiving a packet for forwarding, a router R directly
attached to protocol Y nodes has a mapping from protocol Y
addresses to domains. If either the source or destination
address is mapped to a domain other than 0 (default), then the
packet is encapsulated (unless it's being forwarded directly by
R to another link on which the neighbor is a protocol Y node).
Otherwise, the packet is forwarded in native mode unless the
neighbor to which the packet is to be forwarded is not protocol
Y capable, or if the LSP that announced D indicates that
encapsulation is needed (it came through a tunnel, or the level
2 router that is announcing it notices that its path to the
destination requires encapsulation).
4.10. Tunnel Protocol
When R1 in area A and R2 in area B have a tunnel configured,
they have to exchange information. It is similar to LSP
information, but actual LSPs do not flow over the tunnel.
Therefore, we need to define the format of the information
flowing over the tunnel.
Perlman (Internet-Draft expires end December 1993) [Page 13]
Internet-Draft Further Integration of ISIS June 1993
The information to be included is the Protocol Y information
that would appear in a level 2 LSP.
4.11. Routing Algorithm
Jeff Pickering suggested that routing to D always be toward the
encapsulation destination, whether or not the packet to D needs
to be encapsulated. I found this rather mind-boggling, but I
finally did understand that it works just fine, and it
eliminates potential suboptimality of routing, like when a
packet is initially directed towards D and then, because
encapsulation is required, it gets diverted towards the
encapsulation destination. In most cases, the actual routes are
identical whether the packet is directed towards D or towards
the encapsulation destination.
So the routing algorithm figures out, from possibly multiple
encapsulation destinations, which is the proper encapsulation
destination, and then routes to the encapsulation destination.
The following rules specify how router R chooses how to route to
D.
1. If there is exactly one LSP announcing D as being reachable
within the area, say R1's LSP, then the packet is routed to
R1 regardless of whether there might be other LSPs
advertising R1. (The other LSPs will be advertising it as
reachable outside the area.)
2. If two level 1 LSPs announce D, say R1's and R2's, and they
both specify D as being in the area, then the packet is
routed according to the least cost path to D. (The cost
from R to R1 is added to R1's advertised cost to D, and the
costfrom R to R2 is added to R2's advertised cost to D. If
the cost through R1 is smaller, the packet is routed
towards R1.)
3. Else, (all LSPs announcing D have hops (pseudohops) instead
of IS-IS cost), find the LSP announcing the smallest number
of hops. This applies even if some of the LSPs are level 1
LSPs and some are level 2 LSPs. The LSP advertising the
smallest number of hops is chosen. If more than one LSP
announces the same smallest number of hops, then a level 1
LSP is preferred over a level 2 LSP. If there is a tie
among equal-level LSPs, then the LSP of the closest (in
terms of IS-IS path cost) router is chosen.
Once the LSP is chosen, take the encapsulation destination
reported in that LSP, and the route to D is the route to
Perlman (Internet-Draft expires end December 1993) [Page 14]
Internet-Draft Further Integration of ISIS June 1993
that encapsulation destination.
If the encapsulation destination is outside the area, then
normal IS-IS routing routes to the nearest level 2 router.
Note that this may not be a Protocol Y capable level 2
router. In that case, the packet to D will wind up
gettingencapsulated enroute. We could change the routing
decision to have routing be to the nearest Protocol Y
capable level 2 router, but I don't think it's worth the
complication.
5. Specific Proposal
Some specifics apply to any protocol. This section contains
information that is applicable to any protocol being supported
by Integrated IS-IS.
5.1. Data Packet Encapsulation
When Protocol Y is encapsulated in IP, IP has a one byte
"protocol type" field. Assuming Protocol Y is assigned a
protocol type value, an encapsulated Protocol Y packet looks
like:
# of octets
+----------------------------------+
| IP header (with Protocol type=Y) | variable
+----------------------------------+
| source domain number | 1
+----------------------------------+
| destination domain number | 1
+----------------------------------+
| original protocol Y packet | variable
+----------------------------------+
When Protocol Y is encapsulated in CLNP, there must be a method
of specifying the protocol type of the encapsulated packet.
Either this is done by having some authority allocate the final
byte of the destination address (the SEL octet) as a protocol
type, or the first byte of the data becomes a protocol type,
which also must be assigned by some authority.
Perlman (Internet-Draft expires end December 1993) [Page 15]
Internet-Draft Further Integration of ISIS June 1993
If the first byte of the data is the protocol type, the packet
looks like this:
# of octets
+----------------------------------+
| CLNP header | variable
+----------------------------------+
| protocol type | 1
+----------------------------------+
| source domain number | 1
+----------------------------------+
| destination domain number | 1
+----------------------------------+
| original Protocol Y packet |
+----------------------------------+
If instead the final byte of the destination address ("the
destination NSAP") is used as a protocol type, then the packet
looks like this:
# of octets
+----------------------------------+
| CLNP header | variable
+----------------------------------+
| source domain number | 1
+----------------------------------+
| destination domain number | 1
+----------------------------------+
| original Protocol Y packet |
+----------------------------------+
When encapsulating the packet, the hop count (or "time to live"
as it is called in many protocols) in the original Protocol Y
packet should be decremented by 1.
5.2. "Protocols Supported" Field
This field appears in IS-IS (10589 defined) Hellos, ES-IS (9542
defined) Hellos transmitted by ISs, and LSPs. Values must be
assigned for each Protocol Y we wish to support.
5.3. Network Management Information
5.3.1. Parameters Node-wide (not Per Circuit Or Tunnel)
This is for IS-IS routers that are directly attached to Protocol
Y nodes.
Perlman (Internet-Draft expires end December 1993) [Page 16]
Internet-Draft Further Integration of ISIS June 1993
1. Protocol Y domains for which Protocol Y information should
be included in level 1 IS-IS LSPs
2. Protocol Y domains for which Protocol Y information should
be included in level 2 IS-IS LSPs
3. Protocol Y domains for which Protocol Y information learned
from level 2 LSPs should be included in level 1 IS-IS LSPs
4. (Appletalk specific) flag for whether zone information
should appear in level 1 LSP
????Perhaps a set of net number ranges for which zone
information should appear in LSPs -- others would have to
be gotten explicitly through ZIP.
I strongly recommend we not put zone info into LSPs, and
instead have that information obtained through ZIP.
5. (Appletalk specific) flag for whether zone information
should appear in level 2 LSP
Same comment -- I think zone information shouldn't go into
LSPs
6. flag for whether encapsulation should always be flagged as
necessary (for instance, to get around hop count
limitations in Appletalk). Or if more granularity is
wanted, a set of network numbers (which can be wildcarded,
for instance by specifying a domain) for which
encapsulation should be required.
5.3.2. Parameters Per Circuit
1. set of (Protocol y address, domain) pairs for that circuit.
In the case of Appletalk, an "address" is a network number
range)
2. set of (domain, internal protocol Y network number,
external Protocol Y network number) for address remapping
3. filters for which domains information should pass into or
out of this circuit
4. set of (domain, domain) pairs for which domain pairs are
allowed to intercommunicate (default is "all")
5.3.3. Parameters Per Tunnel
Perlman (Internet-Draft expires end December 1993) [Page 17]
Internet-Draft Further Integration of ISIS June 1993
1. Same information as for a circuit, plus:
2. List of endpoint addresses, to be tried in order (or which
would be acceptable if they initiate the tunnel)
3. Flag for whether this router should initiate the tunnel or
not
4. Set of other routers in area that, if they are up, this
tunnel should not be initiated (this is to prevent multiple
tunnels between the same pair of areas from coming up)
6. Appletalk Specific Proposal
In this section I'll make a specific proposal for Appletalk. A
NLPID needs to be assigned for Appletalk, which will be used in
data packets and in the "protocols supported" field in Hello
messages and LSPs.
6.1. Appletalk Only Environments
If Appletalk is the only protocol, then there are some
simplifications. One can assume there is no hierarchy, so there
is only level 1 LSPs, and no need for inter-area route leaking.
Also, various flags become irrelevant, like the flag for
requiring encapsulation, and the flag indicating whether
something is reachable in the area or not.
6.2. Zone Information
Appletalk requires routers to acquire a zone/LAN mapping table
(where a LAN is represented by a network number range). This can
be done in one of two ways:
1. With the ZIP protocol. For instance, R1 finds out about a
newly reachable network number range from IS-IS router R2,
either because R2 reports it in its LSP, or R2 has a tunnel
to R1. In this case R1 explicitly sends an ordinary
Appletalk ZIP query to R1 requesting the zones list for
that network number range. The protocol message is
encapsulated in a CLNP header (or whatever the backbone
network layer protocol is), addressed to R2. R2 replies
with the appropriate Appletalk ZIP reply, encapsulated with
destination address R1.
2. By including the zones information in the LSP, or in the
protocol used across the tunnel.
Perlman (Internet-Draft expires end December 1993) [Page 18]
Internet-Draft Further Integration of ISIS June 1993
The advantage of the first approach is that it doesn't clutter
up the LSP database with potentially a large volume of
information. Not only is it a large volume of information, but
it doesn't change that frequently and doesn't seem like the type
of thing LSP propagation was designed for. The advantages of the
second approach is that the information propagates more quickly,
changing the zones list for a network number range will work
without ugly hackery, and it is self-stabilizing (if someone for
some reason gets the zones list wrong, it will fix itself when
the LSP information is periodically regenerated). We recommend
the first approach, but allow configuration of routers as to
which network numbers to include zone information for. A router
can be configured to always include zone information, never
include zone information, include or exclude it for certain
domain numbers, or include or exclude it for certain network
number ranges. If the information for a particular network
number range is missing, routers request the missing zone
information with ZIP. So the mechanisms work together.
6.3. LSPs
The "protocols supported" field, which is already specified in
RFC 1195, will have a value for Appletalk.
Also, an option must be added for reporting reachable Appletalk
destinations (network number ranges). I won't pick the option
code.
This option appears in level 1 as well as level 2 LSPs. The only
difference is that the I/E flag is not present in level 2 LSPs.
# of octets
+----------------------------+
| DOMAIN | 1
+----------------------------+
| I/C | E | I/E | E.add len | IP/CLNP/Enc needed/intra-area
+----------------------------+
| ENCAPSULATION DESTINATION |
+----------------------------+
| # of Appletalk destinations|
+----------------------------+
| H/C | COST | 1 - H/C => IS-IS cost or hops
+----------------------------+
| LOW NET NUMBER IN RANGE |
+----------------------------+
| HIGH NET NUMBER IN RANGE |
+----------------------------+
Perlman (Internet-Draft expires end December 1993) [Page 19]
Internet-Draft Further Integration of ISIS June 1993
To save room, this option allows reporting of multiple Appletalk
destinations, so long as they all have the same domain number
and the same encapsulation destination. The I/C flag indicates
whether the encapsulation destination is IP or CLNP. The E flag
indicates whether encapsulation is necessary. The I/E flag
indicates whether the destination is directly reachable through
the area, or whether information about it comes from a different
area. The purpose of this information is so that information
received from tunnels or from level 2 routers (who are relaying
information from other areas) does not get re-exported through
other tunnels. The rest of that octet gives the encapsulation
address length, which will always be 4 for IP. In the case where
the encapsulation destination is the source of the LSP, then
that field is 0, indicating encapsulation address length is 0.
The H/C flag indicates whether the cost given is an IS-IS cost
(which is only true for the first router that introduces D into
IS-IS -level 2 routers that summarize paths always revert to
hops), or pseudohops.
The other option is for zone information. (Note, I personally
don't favor cluttering up LSPs with zone information, since zone
information is rather static -- you get it once and it pretty
much doesn't change. Sending it around in LSPs takes unnecessary
bandwidth and memory. But some people would like to see it in
LSPs. At least it is configurable, so it can be done either
way.) The information in this option will be encoded as in an
Appletalk ZIP reply, starting with the "ZIP function" octet.
7. Specific Proposal for IPX
7.1. Ticks Metric
We will assume there is a configured scaling from IS-IS metrics
to ticks. Within an area, it is therefore straightforward to
find a reasonable ticks value. Assume IPX destination D is
reachable in area A. Assume level 2 router R1 is exporting
information about D in its level 2 LSP. R1 calculates the ticks
value from itself to D and reports that in its level 2 LSP. When
R2 imports information about D into area B, it calculates the
ticks value from itself to R1 (based on scaling the IS-IS path
cost), and adds that to the reported ticks cost in R1's LSP.
Perlman (Internet-Draft expires end December 1993) [Page 20]
Internet-Draft Further Integration of ISIS June 1993
7.2. LSPs
The "protocols supported" field, which is already specified in
RFC 1195, will have a value for IPX.
Option for reporting IPX destinations:
# of octets
+----------------------------+
| DOMAIN | 1
+----------------------------+
| I/C | E | I/E | E.add len | IP/CLNP/Enc needed/intra-area
+----------------------------+
| ENCAPSULATION DESTINATION |
+----------------------------+
| # of IPX destinations |
+----------------------------+
| H/C | COST | 1 - H/C => IS-IS cost or hops
+----------------------------+
| ticks |
+----------------------------+
| NET NUMBER |
+----------------------------+
To save room, this option allows reporting of multiple IPX
destinations, so long as they all have the same domain number,
cost, ticks, and encapsulation destination. The I/C flag
indicates whether the encapsulation destination is IP or CLNP.
The E flag indicates whether encapsulation is necessary. The
rest of that octet gives the encapsulation address length, which
will always be 4 for IP. In the case where the encapsulation
destination is the source of the LSP, then that field is 0,
indicating encapsulation address length is 0. The H/C flag
indicates whether the cost given is an IS-IS cost (which is only
true for the first router that introduces D into IS-IS -level 2
routers that summarize paths always revert to hops), or
pseudohops.
I'm not sure we should bother with SAP information. I heard a
rumor that SAP information will go away in IPX and be replaced
by a naming service kind of thing.
Perlman (Internet-Draft expires end December 1993) [Page 21]
Internet-Draft Further Integration of ISIS June 1993
Option for reporting SAP information:
# of octets
+----------------------------+
| HOPS | 1
+----------------------------+
| SERVER NAME length | 1
+----------------------------+
| SERVER NAME | variable
+----------------------------+
| SERVER ADDRESS | 12 (4=net, 6=ID, 2=socket)
+----------------------------+
| .... | server info (cost, name, add)
+----------------------------+
| HOPS | 1
+----------------------------+
| SERVER NAME length | 1
+----------------------------+
| SERVER NAME | variable
+----------------------------+
| SERVER ADDRESS | 12 (4=net, 6=ID, 2=socket)
+----------------------------+
7.3. IPX-specific Network Management Information
Same information as Appletalk. Perhaps instead of trying to
calculate an inter-area ticks value by scaling IS-IS costs, we
might instead configure an "area ticks increment" and a "level 2
ticks increment" and, for each tunnel, a "tunnel ticks
increment". When reporting D, learned from the area, into a
tunnel or into a level 2 LSP, add the area ticks increment. When
reporting information learned through a tunnel, add the tunnel
ticks increment configured for that tunnel. When reporting
information learned through level 2 LSPs into an area, use the
level 2 ticks increment.
This is simpler and might be sufficiently accurate, especially
since the more complex scheme of trying to figure it out isn't
necessarily right (the packet won't necessarily be routed to the
level 2 router that exported the route to D out of D's area, for
instance).
8. Security Considerations
Security issues are not discussed in this memo.
9. References
Perlman (Internet-Draft expires end December 1993) [Page 22]
Internet-Draft Further Integration of ISIS June 1993
[1]Callon, R.W, "Use of OSI IS-IS for Routing in TCP/IP and dual
environments", RFC 1195, December 1990.
[2]"Information Technology - Telecommunications and information
exchange between systems - Intermediate system to
Intermediate system Intra-Domain routeing exchange protocol
for use in Conjunction with the Protocol for providing the
Connectionless-mode Network Service (ISO 8473)",
International Standard 10589 (ISO submission copy), October
1991.
10. Working Group information
The current co-chairs of the ISIS working group are:
Ross Callon
Wellfleet Communications Inc.
12 DeAngelo Drive
Bedford
MA 01730-2204
USA
Phone: (617) 280 2436
Email: rcallon@wellfleet.com
Chris Gunner
Digital Equipment Corp.
550 King Street
Littleton
MA 01460-1289
USA
Phone: (508) 486 7792
Fax: (508) 486 5279
Email: gunner@dsmail.enet.dec.com
The working group mailing list is:
isis@merit.edu
Subscription requests should be sent to:
isis-request@merit.edu
Perlman (Internet-Draft expires end December 1993) [Page 23]
Internet-Draft Further Integration of ISIS June 1993
11. Author's Address
Radia Perlman
Digital Equipment Corp.
550 King Street
Littleton
MA 01460-1289
USA
Phone: (508) 486 7648
Fax: (508) 486 5279
Email: perlman@dsmail.enet.dec.com
Chris Gunner
(see chair information for address, etc.)
Perlman (Internet-Draft expires end December 1993) [Page 24]
